TD 7 : Modélisation
Modèle Conceptuel des Données
L3 MIASHS |
| Année 2025 |
L’objectif de cette séance est d’élaborer des MCD sur des études de cas.
Modèles Conceptuels des Données avec la modélisation E/A
Exercice 1
Vous êtes engagé au journal SportKan’AP, où vous devez établir le système d’information des tournois de tennis du Grand Chelem. Le système doit mémoriser toutes les rencontres qui se sont déroulées depuis que ces tournois existent, ainsi que leur caractéristiques.
Types de résultats attendus
- Restituer la composition et le score des matches d’un tournoi, une année donnée.
- Restituer la liste des arbitres ayant participé à un tournoi.
- Connaître le pays qui a le plus souvent remporté le simple aux Internationaux de France.
- Restituer les gains d’un joueur dans les tournois du Grand Chelem.
- Établir la liste des différents entraîneurs d’un joueur…
Précisions sur le système d’information
- Il y a chaque année quatre tournois du Grand Chelem. Ils se déroulent dans les pays suivants : États-Unis, France, Grande-Bretagne, Australie. Pour un pays, ils peuvent se dérouler dans des endroits différents, ainsi aux États-Unis ils se sont déroulés à Forest Hill, puis à Flushing Meadow.
- A chaque match est associé un gain, c’est celui du perdant. Par exemple au premier tour des tournois simples, à Roland-Garros en 2025, le joueur qui perd gagne 78 000 €, au deuxième tour, 117 000 €, etc. Les vainqueurs des tournois simples féminin ou masculin ont gagné le prix associé au tournoi, c’est-à-dire 2,55 millions d’euros.
- Lors de ces tournois il y a neuf épreuves : simples et doubles féminins et masculins, double mixte, tennis-fauteuil simples et doubles, Quad simples et doubles.
- Un joueur peut changer de nationalité, et même être apatride. Navratilova, d’origine tchèque, fut tour à tour apatride puis américaine.
Phrases du système d’information
- Iga Świątek a battu Nadia Podoroska à Roland-Garros en 2020 en 1/2 finale du simple féminin par 6‑2/6‑1.
- Monsieur Wilkinson arbitra ce match (NB : cette information a été inventée pour l’exercice).
- Le simple féminin de Roland-Garros a été remporté trois fois par une joueuse polonaise.
- Björn Borg a gagné 2 millions $ au cours de ses participations aux tournois du Grand-Chelem (avec 11 titres).
- Le vainqueur masculin de Roland-Garros en 2025 a gagné 2,55 millions €.
- Yannick Noah a joué 4 fois en double mixte avec Hana Mandlíková.
Solution
Dictionnaire des données
Version 1
| Nom | Signification |
|---|---|
| nom tournoi | Nom d’un tournoi |
| pays | Pays d’un tournoi |
| lieu | Lieu d’un tournoi |
| année | Année d’un tournoi |
| prix | Prix d’un tournoi |
| nom joueur | Nom d’un joueur |
| sexe | Sexe d’un joueur |
| nationalité | Nationalité d’un joueur |
| score | Score d’un match |
| date | Date d’un match |
| gain perdant | Gain du perdant d’un match |
| type | Type d’un match (simple messieurs, simple dames, double dames,…) |
| tour | Tour d’un match (finale, demi finale,…) |
| nom arbitre | Nom de l’arbitre d’un match |
| nom entraîneur | Nom de l’entraîneur d’un joueur |
Recherche des entités, de leurs identifiants et propriétés
On a les entités évidentes suivantes :
Entité TOURNOI, propriétés évidentes : numéro tournoi, nom tournoi, année. Ces deux propriétés sont bien en dépendance fonctionnelle directe et complète de l’identifiant.
- numéro tournoi \(\rightarrow\) prix ?
Cette dépendance fonctionnelle n’est pas vérifiée car le prix d’un tournoi varie en fonction du type (simple, double, etc.). On a donc la dépendance : numéro tournoi + type \(\rightarrow\) prix Comme nous le verrons par la suite, cela impose de créer une entité TYPE. prix sera la propriété d’une association entre TOURNOI et TYPE. - numéro tournoi \(\rightarrow\) lieu ?
Il est dit qu’un tournoi peut se dérouler dans des lieux différents, néanmoins l’énoncé sous-entend que pour une année donnée, le lieu est unique. Or l’entité tournoi correspond à une année donnée. On a donc bien : numéro tournoi \(\rightarrow\) lieu. A priori, il est possible de faire de lieu une propriété de TOURNOI. - numéro tournoi \(\rightarrow\) pays ?
Cette dépendance est évidente. Mais on a aussi lieu \(\rightarrow\) pays, donc pays n’est pas en dépendance directe de numéro tournoi, ce n’est donc pas une propriété de TOURNOI. On doit donc créer une entité PAYS avec comme identifiant nom pays. Cet identifiant est pratique mais il posera problème si un des pays change de nom. - La dépendance fonctionnelle lieu \(\rightarrow\) pays conduit à créer une entité LIEU. Pour cette raison, lieu n’est pas une propriété de TOURNOI.
- numéro tournoi \(\rightarrow\) prix ?
Entité JOUEUR, propriétés évidentes : numéro joueur, nom joueur, sexe. Ces deux propriétés sont bien en dépendance fonctionnelle directe et complète de l’identifiant.
- numéro joueur \(\rightarrow\) nationalité ?
La nationalité peut varier dans le temps et on veut conserver les nationalités successives d’un joueur pour calculer le nombre de victoire par pays. Il faut donc enregistrer l’historique des nationalités de chaque joueur. Il n’y a donc pas de dépendance fonctionnelle entre numéro joueur et nationalité, ce n’est pas une propriété de l’entité JOUEUR. En rangeant nationalité comme propriété de joueur on attribuerait toutes les victoires de Navratilova aux États-unis, alors que cette joueuse a été successivement tchèque, apatride, puis américaine. - numéro joueur \(\rightarrow\) nom entraîneur ?
Cette dépendance fonctionnelle n’est pas vérifiée car un joueur peut changer d’arbitre et le SI doit conserver cet historique. Il faut donc créer une entité ENTRAÎNEUR.
- numéro joueur \(\rightarrow\) nationalité ?
Concernant les matchs, il peut être tentant d’en faire une association réflexive sur JOUEUR, les propriétés de cette association étant score, type, gain perdant, tour et arbitre. On obtiendrait le modèle suivant :
Mais une rencontre ainsi modélisée ne met en présence que deux joueurs : elle ne peut représenter que les simples ! Il faudrait donc créer une deuxième association à cinq arêtes pour les doubles. Le modèle n’est donc pas satisfaisant. De plus, on a déjà vu qu’il fallait faire de type une entité, ce n’est donc pas une propriété de l’association rencontrer car alors la même propriété serait présente deux fois dans le modèle. Cela obligerait donc à ajouter une arête vers l’entité TYPE à ces associations. On obtiendrait donc des associations à 4 et 6 arêtes (simples et doubles).
On choisit donc, comme classiquement lorsqu’apparaît une association quaternaire et plus, de créer une entité MATCH, avec comme identifiant numéro match et comme propriétés évidentes score, date.- numéro match \(\rightarrow\) gain perdant ?
Cette dépendance fonctionnelle est vérifiée, mais elle n’est pas directe. En effet, tous les matchs d’un même type et d’un même tour offrent le même gain. On a numéro match \(\rightarrow\) numéro tournoi+type+tour \(\rightarrow\) gain perdant. Comme nous le verrons à propos des associations, cela oblige à créer une entité supplémentaire TOUR. - numéro match \(\rightarrow\) nom arbitre ?
Cette dépendance fonctionnelle est vérifiée, elle est directe et complète, on peut donc faire de nom arbitre une propriété de MATCH, mais cette solution ne permet pas d’enregistrer dans la base une liste d’arbitre et des propriétés éventuelles qui leur seraient propres. Il est donc préférable de créer une entité ARBITRE.
- numéro match \(\rightarrow\) gain perdant ?
Version 2 du dictionnaire des données
| Nom | Signification |
|---|---|
| numéro tournoi | Identifiant de TOURNOI |
| nom tournoi | Nom d’un tournoi |
| nom pays | Nom du pays d’un tournoi |
| nom lieu | Nom du lieu d’un tournoi |
| année | Année d’un tournoi |
| prix | Prix d’un tournoi |
| numéro joueur | Identifiant de JOUEUR |
| nom joueur | Nom d’un joueur |
| sexe | Sexe d’un joueur |
| numéro entraîneur | Identifiant de ENTRAINEUR |
| nom entraîneur | Nom de l’entraîneur d’un joueur |
| numéro match | Identifiant de MATCH |
| date | Date d’un match |
| tour | Tour d’un match (finale, demi finale,…) |
| type | Type d’un match |
| score | Score d’un match |
| gain perdant | Gain du perdant d’un match |
| numéro arbitre | Identifiant de ARBITRE |
| nom arbitre | Nom de l’arbitre d’un match |
Graphe des dépendances fonctionnelles
Mise en place des associations
Les dépendances fonctionnelles : l’étude du graphe des dépendances fonctionnelles permet de déduire immédiatement les associations binaires qui sont des dépendances fonctionnelles :
- Association «appartient» entre MATCH et TOURNOI
- Association «se situe» entre LIEU et PAYS. Si lieu était une propriété de TOURNOI comme évoqué précédemment, alors cette association lierait TOURNOI à PAYS. Étant donné le graphe des dépendances fonctionnelles (numéro tournoi \(\rightarrow\) nom lieu \(\rightarrow\) nom pays), cette association aurait des instances redondantes, ce qui est à éviter.
- Association «se déroule» entre TOURNOI et LIEU pour compléter la précédente.
- Association «de type» entre MATCH et TYPE.
- Association «arbitré par» entre MATCH et ARBITRE.
- Association «de tour» entre MATCH et TOUR.
La nationalité : Un joueur peut avoir à une période plusieurs nationalités, une seule, ou bien encore aucune. On crée une association «de nationalité» entre JOUEUR, PAYS et DATE, l’arête sur DATE correspondant à la date d’acquisition de la nationalité. On ajoute une propriété date de fin correspondant à la date à laquelle un joueur perd une nationalité.
Les entraîneurs : Un joueur peut avoir à une période plusieurs entraîneurs, un seul, ou bien encore aucun. On crée une association «est entraîné par» entre JOUEUR, ENTRAÎNEUR et DATE, l’arête sur DATE correspondant à la date de début de la coopération entre le joueur et l’entraîneur. On ajoute une propriété date de fin correspondant à la fin de cette coopération.
La composition des matchs : on peut envisager trois solutions :
- Première solution : Une association «participer» indique les compositions des matches. Une association «gagner» indique le ou les gagnants (double).
- Seconde solution : une association «participer» portant une propriété prenant la valeur vrai ou faux selon que le joueur a gagné ou non.
- Troisième solution : deux associations «gagner» et «perdre».
Pour les solutions 1 et 3, il faut compléter le MCD par des contraintes interassociation. C’est la solution 2 qui est choisie pour des raisons de simplicité.
Le prix d’un tournoi : d’après numéro tournoi + type \(\rightarrow\) prix, on créer une association «recevoir prix» entre TOURNOI et TYPE ayant la propriété Prix tournoi.
Le gain du perdant : d’après numéro tournoi+type+tour \(\rightarrow\) gain perdant, on créer une association ternaire «recevoir gain» entre TOURNOI, TOUR et TYPE ayant la propriété Prix tournoi. Ce qui signifie que pour un tour d’un tournoi, tous les matches de même type ont la même valeur de gain perdant.
MCD Complet
Exercice 2
Un grand organisme dispose de véhicules de service. Ceux-ci peuvent être prêtés aux membres du personnel pour effectuer des missions.
- Le système d’information à concevoir doit être en mesure de gérer l’historique des interventions sur les véhicules (réparations et entretiens périodiques).
- Il doit également permettre de connaître les principaux utilisateurs (personne et service utilisateur) de manière à pouvoir dresser des statistiques d’utilisation.
- Il sera possible de connaître à tout moment si un véhicule est disponible.
- Enfin il doit être possible de connaître la liste prévisionnelle des véhicules à envoyer à l’entretien.
Types de résultats attendus
- Liste des véhicules disponibles.
- Liste prévisionnelle des entretiens à effectuer.
- Coût au km des réparations pour un véhicule.
- Coût au km des entretiens pour un véhicule.
- Coût au km (tout frais confondus) pour un véhicule.
- Nombre de kilomètres parcourus par une personne.
- Nombre de kilomètres parcourus par l’ensemble des personnes d’un service…
Phrases du système d’information
- Monsieur Jean-Baptiste LAGAFFE a emprunté le véhicule DJ-325-KN du 20/05/24 à 13h au 23/05/24 à 17h et a parcouru 596 km, la facture d’essence s’élevant à 60 €.
- Le garage RENÉ CETOUFER a réparé le véhicule DJ-325-KN du 12/05/24 au 15/05/24, le montant de l’intervention s’est élevé à 2200 € TTC.
- Les Renault Clio full hybrid E-Tech doivent être portées en révision aux kilométrages suivants 5 000, 10 000 puis tous les 25 000 kilomètres.
- La voiture FV-861-GH est une Renault Clio full hybrid E-Tech achetée le 3/09/2025.
Précision sur le système d’information
- Une personne ne dépend que d’un service.
Solution
Dictionnaire des données
| Nom | Signification |
|---|---|
| N° immatriculation | |
| Type véhicule | Modèle |
| Date achat | Date d’achat d’un véhicule par la société |
| Kilométrage | Kilométrage total d’un véhicule de la société |
| Kilométrage révision | Kilométrage pour lequel un type de véhicule doit être révisé |
| Nom emprunteur | Nom de membre du personnel emprunteur |
| Nom service | Nom de service de la société |
| Date emprunt | Date d’emprunt d’un véhicule par un membre du personnel |
| Heure emprunt | Heure d’emprunt d’un véhicule par un membre du personnel |
| Date retour | Date de retour d’un véhicule par un membre du personnel |
| Heure retour | Heure de retour d’un véhicule par un membre du personnel |
| Nbre kilomètres | Nombre de kilomètres parcourus lors d’un emprunt |
| Montant facture essence | Montant de la facture de carburant lors d’un emprunt |
| Prix réparation | Prix d’une réparation d’un véhicule |
| Date début réparation | Date de début de la réparation d’un véhicule |
| Date fin réparation | Date de fin de la réparation d’un véhicule |
| Prix révision | Prix d’une réparation d’un véhicule |
| Date début révision | Date de début de la révision d’un véhicule |
| Date fin révision | Date de fin de la réparation d’un véhicule |
| Nom garage |
Recherche des entités et de leurs identifiants
- Entité VÉHICULE, identifiant : N° d’immatriculation
- Entité EMPRUNTEUR, identifiant : N° emprunteur
- Entité SERVICE, identifiant : Nom service
- Entité GARAGE, identifiant : N° garage
- Entité TYPE DE VÉHICULE, identifiant : N° type. En effet, comme kilométrage révision dépend du type de véhicule, il s’agit bien d’une entité.
Recherche des propriétés des entités
On essaie d’attribuer les propriétés restantes en vérifiant à chaque fois la règle de dépendance fonctionnelle directe et complète des propriétés par rapport à l’identifiant.
- Date achat : propriété de l’entité VÉHICULE, on a bien N° immatriculation \(\rightarrow\) Date achat
- Kilométrage : propriété de l’entité VÉHICULE, on a bien N° immatriculation \(\rightarrow\) Kilométrage
- Kilométrage révision ? Pour un type de véhicule, il y a plusieurs occurrences de kilométrage de révision, ce n’est donc pas une propriété de type de véhicule. Nous verrons lors de l’étude des associations comment régler ce problème.
- Nom type : propriété de l’entité TYPE DE VÉHICULE, on a bien N° type \(\rightarrow\) Nom type.
- Nom emprunteur : propriété de l’entité EMPRUNTEUR, on a bien N° emprunteur \(\rightarrow\) Nom emprunteur
- Données concernant un emprunt : Date emprunt, Heure emprunt, Date retour, Heure retour, Montant facture essence. Elles ne sont pas uniques, ni pour un emprunteur, ni pour un véhicule et ne sont donc pas des propriétés de ces entités.
- Données concernant une réparation ou une révision : Prix réparation, Date début réparation, Date fin réparation, Prix révision, Date début révision, Date fin révision. Elles ne sont pas uniques, ni pour un garage, ni pour un véhicule et ne sont donc pas des propriétés de ces entités.
- Nom garage : propriété de l’entité GARAGE, on a bien N° garage \(\rightarrow\) Nom de garage
Mise en place des associations
Les dépendances fonctionnelles :
- Association «attaché» entre EMPRUNTEUR et SERVICE : tout emprunteur est attaché à un service et un seul.
- Association «est de» entre VÉHICULE et TYPE : tout véhicule est d’un type et un seul.
Réparations : Parmi les propriétés non encore mises en place, il a Prix réparation, Date début réparation, Date fin réparation.
Le prix d’une réparation est unique pour un véhicule et une date/heure. On a donc la dépendance fonctionnelle : (N° d’immatriculation, date début réparation) \(\rightarrow\) Prix réparation
Le prix d’une réparation est donc une propriété de l’association «réparer».
Nous avons ici signifié qu’un véhicule a été porté en réparation à une date/heure, il reste à représenter la date de retour du véhicule. La solution consistant à modéliser comme ci dessous est erronée :
En effet, à un moment donné dans ce système d’information certaines occurrences de l’association «réparer» sont à trois arêtes (les réparations terminées), alors que d’autres sont à deux arêtes (les réparations en cours). Ceci est interdit. De plus, l’arête (retour) sur DATE est inutile pour identifier l’association.
Nous avons donc le choix entre deux modélisations possibles.
- La première consiste à créer une propriété Durée ou Date de retour dans l’association «réparer».
- La seconde à créer une autre association : «revenir de réparation». Lors de l’insertion d’une occurrence de «revenir de réparation», il faut vérifier que celle-ci correspond à une occurrence de «porter à réparer». Pour cela, il faut ajouter une contrainte d’intégrité d’inclusion entre les deux associations.
La première solution est la meilleure car elle est plus simple.
Pour représenter le fait qu’un véhicule est porté en réparation dans un garage, on ne peut ranger «Nom garage» dans l’association car il existe déjà une entité GARAGE (une propriété se trouve à un seul endroit du modèle). Il faut alors ajouter alors une arête à l’association «réparer» qui indiquera le garage concerné par la réparation.
Les révisions : le même raisonnement est tenu pour les associations «réviser» et «emprunter». Les propriétés «Prix révision» et «Durée révision» sont rangées dans «réviser».
Emprunt : les emprunts sont modélisés par une association «emprunter» entre VÉHICULE, EMPRUNTEUR et DATE conformément à la gestion classique du temps. A noter que la date est en fait une date/heure puisque les heures sont nécessaires au SI. On pourrait introduire une entité EMPRUNT mais cela ne doit être fait que s’il existe déjà un identifiant (un numéro d’emprunt) dans la gestion de la société ou bien si la vérification des règles de normalisation nous y contraint. Les propriétés Montant facture essence, Nbre kilomètres et Durée emprunt sont rangés dans «emprunter», et une contrainte d’intégrité fonctionnelle est placée entre «emprunter» et EMPRUNTEUR, puisqu’à un moment donné pour un VÉHICULE il n’y a qu’un emprunteur.
Kilométrage révision : nous avons vu que cette donnée n’est pas une propriété d’une des entités existante car elle n’est en dépendance fonctionnelle d’aucune autre donnée élémentaire. Il faut nécessairement créer une entité LIMITE avec pour identifiant Kilométrage révision. L’association «à réviser» enregistre les kilométrages de révisions d’un type de véhicule.
MCD Complet
